necesitamos referir a MD Links? o podemos decir "Te sugerimos implementar las siguientes funcionalidades para que puedas reforzar los objetivos de aprendizaje de promesas, si aun no has creado promesas en otro proyecto" algo asi?

Si, también siento que se puede omitir mencionar MD links

Si, es cierto podemos omitirlo

Estoy de acuerdo en omitir a MD-Links! y me parece bien el texto que ofrece Ivy, pero quizás no lo dejaría solo para quienes no han hecho promesas en sus proyectos anteriores... quizás lo dejaría como "...trabajar y/o reforzar objetivos de aprendizaje de promesas", en caso de que alguien quiera seguir reforzando lo aprendido en MD-links pero no necesariamente quiera realizar el proyecto de Burger Queen API.

este herokuapp es algo que hemos escrito y podemos garantizar que siempre va a estar?
pensando que quiza podemos incluir un function que resuelva su Promesa con status 200 o 500 aleatoriamente, para no tienes que depender en otro servicio

@ssinuco quién es owner de esta API? hay repo?
En caso de que seas tu el owner, estaría bueno que la API devuelva un parámetro booleano con el descuento ej:

{
  "gotDiscount": true,
  "msg": "Has obtenido un 50% de descuento"
}

Si yo escribi esta app. Es muy sencilla, de forma aleatoria devuelve 200 o 500. Lo ideal es transferirla a un perfil de laboratoria o que la estudiante la mocke, que opinan que sean mejor @unjust y @santiaguf ?

@santiaguf agrego entonces el parametro que sugeriste, gracias

Si quieres, la puedes transferir como repo de laboratoria, es decir, forkear desde tu perfil al de laboratoria, de tal suerte que quede algo como:
https://github.com/laboratoria/buger-queen-discount forked from https://github.com/ssinuco/buger-queen-discount

Agregaría una sugerencia de empezar realizando un diagrama de flujo, como para que tengan una idea más visual de como funcionaría esto.

Si yo escribi esta app. Es muy sencilla, de forma aleatoria devuelve 200 o 500. Lo ideal es transferirla a un perfil de laboratoria o que la estudiante la mocke, que opinan que sean mejor @unjust y @santiaguf ?

@santiaguf agrego entonces el parametro que sugeriste, gracias

Prefiero ponerlo en un repo Laboratoria o archivo dentro del proyecto. El mock puede ser opcional, creo puede ser mucho para alguien que todavía falta promesas no se.

Estoy de acuerdo en que depender de una API externa mantenida por un coach puede ser problemático. ¿Qué les parecería sugerir que implementen un mock de este tipo?

const getDiscount = () => new Promise((resolve, reject) => {
  setTimeout(() => {
    const discount = parseInt(Math.random() * 100);
    if (discount > 80) {
      return reject(new Error(`${discount}% es demasiado descuento!`));
    }
    return resolve(discount);
  }, 0);
});

Acabo de ver que la API devuelve un código de status 500 cuando no hay descuento:

Un 500 debe devolverse cuando hay un error en el servidor, y este no es el caso, yo sugiero que cuando no haya descuento, devuelva 200 pero tenga un parámetro en el body de la respuesta:

{
  "gotDiscount": false,
  "msg": "Esta vez no tienes descuento. Inténtalo en tu próxima visita"
}

Tienes razon @santiaguf. En los dos casos deberia responder 200 y variar la llave gotDiscount. Lo que queria hacer era que la estudiante lideara con multiples codigos http. ¿Es muy enredado dejar que el servicio responda 200 con gotDiscount en true y false pero que de forma aleatoria tambien falle con 500?

Creo que para eso podrías usar una respuesta 404 (descuento no encontrado).
Tal cómo mencionan en esta guía, es mejor evitar los códigos 500.

Mira ssinuco/buger-queen-discount#1

Hola @ssinuco @adolivaresl @unjust y @lupomontero !

Perdón por haber dejado pasar este PR por tanto tiempo 🙏

Estoy de acuerdo con la observación que hace Ivy, con respecto a no depender de un servicio 3erizado en Heroku o algo así, y me gusta mucho la implementación de Lupo, que devuelve un Error en caso de que el descuento sea muy grande! Creo que por ahí debería venir esa solución.

Con respecto a esta sección tengo mis dudas... ¿Es realmente el modus operandi de un restaurant el esperar a que todo el pedido de la mesa esté listo para entregarlo a una mesa?

Entiendo el punto de que ayudaría a reforzar el OA asociado a promesas, y que suena como una buena excusa para introducir Promise.all() pero no sé qué tan adecuado sea el ejemplo.

¿Le estoy dando mucho color? Quizás le estoy dando demasiada vuelta a algo que no lo merece, ¿Qué opinan?

En todo caso, creo que algo de eso sí ocurre, pero en mi experiencia, creo que las cosas suelen ser entregadas en dos tandas:

1. Los bebestibles
2. La comida

¿Quizás podemos reforzar este punto hablando un poco de eso? Es decir, esperar a que todos los bebestibles del pedido de una mesa estén listos para entregarlos, y luego lo mismo, pero con la comida? ¿O lo estoy complicando demasiado? 😁

@mfdebian de acuerdo con tu ejemplo de mundo actual, bebidas o piqueos primero, plato principal despues, pero creo por el proyecto y como los pedidos y modelo estan diseñado, seria mejor que un pedido entero es listo - es como siempre Burger Queen ha sido implementado.
Y Promise.all() podemos usar por mesas (pedidos) multiples. Al menos empezamos aqui, y si las estudiantes quieren llevar la tema mas alla, pueden.

listo! actualizaré el PR entonces 😊

Hay que editar eso entonces y incluir el funcion que responde un status https://github.com/Laboratoria/bootcamp/pull/1158#discussion_r892966656 en otro archivo

@unjust @mfdebian @ssinuco Sergio, te recomiendo que ese webservice del descuento lo despliegues en otro servicio gratuito como Glitch, dado que Heroku terminará su servicio gratuito en 3 semanas

gracias @santiaguf !! al final optaremos por dejar una función que entregue un número aleatorio de manera asíncrona en forma de promesa, para que ninguna coach tenga que estar manteniendo algún servicio con respecto a eso, muchas gracias nuevamente!